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Abstract 

Frog [1 1 is a generic framework dedicated to visualisation of events in high energy experiment. It 
is suitable to any particular physics experiment or detector design. The code is light (< 3 MB) and 
fast (browsing time ~ 20 events per second for a large High Energy Physics experiment) and can 
run on various operating systems, as its object-oriented structure (C++) relies on the cross-platform 
OpenGL [2 | and Glut (3) libraries. Moreover, Frog does not require installation of third party 
libraries for the visualisation. This document describes the features and principles of Frog version 
1.106, its working scheme and numerous functionalities such as: 3D and 2D visualisations, graphical 
user interface, mouse interface, configuration files, production of pictures of various formai 1 ! inte- 
gration of personal objects, etc. Finally, several examples of its current applications are presented for 
illustration. 
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1 Introduction 



In high energy physics experiments, the possibility to visualise each event is crucial for several reasons. Under- 
standing the event topologies can help in developing better data analysis algorithms. It can also be used as a 
powerful debugging tool for the simulation and reconstruction experiment softwares. 

A visualisation tool has to be : 

• fluid : draw > 60 frames per second 

• fast : scan hundreds of events in few seconds 

• light : the entire package should not exceed 10 MB 

• easily upgradable 

• an intuitive debugging tool 

• able to provide nice illustrations for communications 

Satisfying simultaneously the above requirements could require heavy usage of all the resources of a computer. In 
general, these resources are the main limitation of the 3D visualisation. In large experiments such as CMS H, 
complex algorithms are used to reconstruct and analyse physics data. Since these algorithms are processor and 
memory consuming, a fast visualisation tool should be decoupled from simultaneous physics calculations. 

The FROG [ 1 1 philosophy is to divide the software into a Producer and a Displayer (Figure[T}. It has an impact on 
several other elements of the software, like the input file format, the operating system portability and the structure 
of the software. A dedicated Frog File Format (FFF) is needed in order to make the two parts of the code 
communicate with each other. It has to be highly compact, but the decoding time of the files has also to remain as 
reduced as possible. Finally, the FFF should also be flexible enough. Its binary encoding ensures its universality 
with respect to the computer type and to the operating systems. The FFF is described in more detail in Section|2] 

The Producer The File Format The Displayer 

Experimental Setup Dependent Any OS and Computer 
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Figure 1: Factorisation of Frog into the Producer and Displayer components. The Producer is integrated in the 
experimental software. It extracts, processes and stores the data required by the Displayer, using the FROG File 
Format for data encapsulation. The Displayer is completely disconnected from the experimental software. 



The Producer (Section [3) is the interface between the physics software of the detector/experiment and the Frog 
Displayer. This code depends on the respective experiment software but it does not require specific graphical 
libraries. Its task is to extract and process once for all the data required by the Displayer. For instance, it can 
convert the position of a hit from local coordinates of the detector to global coordinates. Such computations are in 
general relatively fast but can slow down the 3D visualisation when repeated many times. The Producer creates two 
separates files, one containing the processed geometry data ( . geom) and one containing the needed events data 
(.vis). This is the part that the user has to adapt in order to make Frog working for his particular experiment. 

The Displayer (Section |4| has the unique function of displaying the content of the . geom and .vis files. It 
is independent from the experiment software. The Displayer can be distributed and run on different platforms : 
Windows, Linux and MacOS are currently supported. The only requirement to execute the Displayer is to use 
some graphic libraries like OpenGL and Glut (3). 
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Frog is completely generic in the sense that it has been designed to be usable for any experiment and also to 
allow everybody to easily upgrade/add some files in order to use Frog for his particular case. It can then be 
used eventually for other purposes. The two parts of the code, the Producer and the Displayer are described 
respectively in Section [3] and |U Additional features are described in Section [5] A few applications of Frog 
in specific detector setups/environments are given in Section [6] Future developments of the Frog Package are 
summarized in Section [7] The two appendices |9j\ and [9}} describe in detail the design and implementation of the 
software. 

2 Frog File Format 

The FROG File Format (FFF) will first be described since it is of crucial importance and has a significant impact on 
the program structure. Since Frog has to be completely generic and has to store needed data in the most compact 
way, the dedicated file format is based on a binary encoding, where data are organised in chunks. Each chunk 
contains an Id that specifies the chunk type, a Size that indicates the chunk end, and the Data themselves. The 
chunk Id is written on 2 Bytes, so 2 16 = 65 536 different chunk types can be handled. The Size is written on 
4 Bytes, so the chunk size is limited to 2 32 = 4 GBytes. The Size is defined as : 

Size = sizeof(W) + sizeof(S;'ze) + sizeof(Dato) = 6 + sizcof(Dato) 

The chunks can contain any type of data, which ensures a maximal flexibility to the software. They can be divided 
into two categories : chunks that contains sub-chunks and those that don't. By similarity with trees, the firsts are 
called "branches" while the others are called "leaves". The branches are useful to group together all data of a same 
experiment/detector/region. See Fig. [2] 




Track #1 



Figure 2: A schematic view of the tree structure of a FFF. 

A file always contains a unique primary chunk that encapsulates, in its Data part, all the other chunks, it's the root 
of the data tree. It must be of type C_PRIMARY=55555. When the primary chunk Size is not equal to the file 
size, the file is assumed to be corrupted. The experiment data (e.g. the detector geometry or the event signals) are 
contained in the sub-chunks of this primary chunk. The chunk structure is illustrated in Figure[3] 
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Figure 3: Example of data file. The primary chunk contains two sub-chunks storing an integer and a float. 

It is often possible to optimize the way data are stored. For instance, if a large number of data of the same type 
and the same size are stored (e.g. 100 Int32) in a mother chunk. It is clear that it is only needed to define the 
size and the type once for all the data. This optimized chunk is represented on Figure |4] The best storing method 
is automatically chosen by Frog in order to reduce the file size. The definition of the chunk structures and the 
related methods can be found in the files: FROG/FROG_Chunk . cpp and FROG/FROG_Chunk . h files. 
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Figure 4: Example of the chunk structure if the file contains 100 Int32. 
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3 Frog Producer 



The Frog Producer builds the Events and the Geometry of a particular detector and stores them into .vis and 
. geom files. It is the interface between the detector software ^1 and FROG. A FROG Producer already exists for 
the CMSSW environment. The Producer is the only part of FROG that has to be interfaced to the user needs, and 
to the experiment software and data format. 

The Producer is in general a part of code (generally C++) that converts the experiment data format to the FFF 
Since the Producer does not use specific graphical libraries it can be run in parallel on a computer cluster. The 
many output . vis files can be merged in a unique file using the Frog merger included in the Frog package. 
This tool is extremely fast since it just puts the event chunks spread into many files, in the same primary chunk of 
a unique file. 

The experiment software only needs to include the textscFrog classes definition in order to produce the . vis and 
. geom. This reduced Frog package, containing only the class definition, takes of the order of ~ 0.5MB on disk 
and is freely distributable. 

A Producer example code of a fictitious experiment composed of a particle source beam, eleven tracking layers and 
a block to stop the beam, can be found in the appendix|9] This example is also available online as a tutorial 0. 

4 Frog Displayer 

This part of the code is completely independent of the detector and does not need to be modified by the Frog 
users. The code uses extensively the OpenGL library and is programmed such as to keep the rendering of events 
fast. 

All the style parameters are loaded from the configuration file (conf ig . txt). The geometry and the current 
event are displayed in the different 3D/2D views. The display of the first frame can be slow, but then, thanks to the 
the OpenGL Display Lists, the Displayer can render more than 60 frames per second. 

Another technique is used to make the display faster for secondary views : after the first draw, an internal screenshot 
of the view is taken, then, this screenshot is just used to redraw the view. From time to time the screenshot is 
updated. However the main view does not use this technique. 

The mouse clicks are handled in order to outline (flashing) and print out information of the mouse selected object. 

The Figure|5]shows how the simulated events produced in the appendix|9]looks in the Frog Displayer. The Frog 
configuration file used to get this view is available in the same appendix. 




Figure 5: Three different Frog Display views: big 3D view (top), 2D longitudinal (bottom right), transversal view 
(bottom left). The different geometry parts are well visible : Particle Gun (grey), the Ending Block (grey) and the 
eleven tracking layers (blue). The particle track is shown in red. 



Two examples of detector software are CMSSW in the CMS experiment and Athena in the ATLAS experiment. 
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5 Features 



5.1 Config File 

Frog is fully configurable by a set of parameters defined in an ASCII file (FROG/conf ig . txt). This file 
contains, amongst other things: 

• the path to the Input . vis file and/or Input . geom file. 

• the first event to display. 

• the objects colour, styles and thresholds. 

• the views to be used. 

The parameters may also be defined in other ASCII files that are included by the main configuration file. Many of 
these options will be described in the next sections. 

5.2 Web interface 

The event ( . vis) and geometry ( . geom) files can be downloaded via internet (world wide web) via the http or 
ftp protocols. This can be steered by setting the URL in the configuration file. For example: 

• InputVisFile = {http://projects.hepforge.org/frog/tut/02/SimulatedEvents.vis}; 

• InputGeom = {http://projects.hepforge.org/frog/tut/02/MyCustomTracker.geom}; 

Frog will download automatically the files using the free libcurl URL transfer library: LibCURL |6|. Some 

future planned developments that will extend this functionality are discussed in Section |7TT| 

It is possible to update the event file periodically in intervals of time defined in the configuration file: 

• update VisFileTime =10; // File Update Interval in seconds 

In this particular case, the event file will be downloaded in a new thread each 10 seconds. When negative values 
are used the file is not updated. This feature can be useful for visualisation of online events where small . vis files 
would be produced periodically. These .vis files could then be put on an http or ftp server and be accessible to 
every users which have Frog installed on their computer. Here, the advantage of using multi-threading is clean: 
the visualisation of the events is not stopped during the download, and the screen would not be frozen. 

5.3 Gzipped files 

Thanks to ZLIB [7 ], Frog can read gzipped .vis/ .geom files automatically, but can also create such files. It is 
for example very useful to create automatically . vis . gz files instead of .vis files, in particular when the files 
are distributed to the users via internet. The compression rate is around 50% depending on the event data contained 
in the . vis files. 

5.4 Different Views 

A flexible view system is implemented in Frog in order to increase the number of possible views in the same 
frame. The user can always create the set of views that suits him best only by changing the configuration file. 
Different types of view are available. The first one is a 3D view of the detector. The view is defined by a set of 
parameters in the configuration file: 

• The viewport: region of the screen that should contain the camera view (X,Y,W,H) 

• The Camera Target (X,Y,Z) 

• The Camera Position on a sphere centered on the target (R,<f>,rf). 

• The movement of the camera (animate or not) 
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• The geometry parts to be displayed in this view 

The second view type is a 2D orthogonal projection view, which is defined also by a set of parameters. Most 
of them are common with the 3D view. The 2D views can't be animated. A new parameter is used to define 
the volume to be projected on the screen. This volume is a cuboid centered on the camera target, with a surface 
equal to the screen dimension. The volume deep is given by the parameter Slide_Depth. So, in the particular 
case where the 2D camera is aligned with the z axis, the projected objects are contained within an interval in z: 
[target . z-Slide_Depth, target . z + Slide_Depth] . A Lego Plot view of specific detectors (e.g. the 
calorimeter cells) can also be used. The code that defines the view classes is fully tunable in order to add easily 
new view types 0. 

5.5 Tree menu 

A menu accessible with key <F2> is included in the Frog Displayer. This menu is very important and simplifies 
a lot the use of Frog. The menu is used to specify what content of the .vis/ . geora files to display with a user 
friendly interface in the form of a structural tree which reflects the structure of the .vis/.geom file (see Fig. |2}. 
Branches of the tree represent group of objects (detector or event data). A branch can be opened to see what it 
contents. The user can also check and modify the display states of the branch (whether or not visible). A second 
menu is accessible by the key <t>. The <t> menu is defined as a semi-transparent view that is superimposed 
on top of the other views. It is useful to see in real time the displayed objects changing when states in the menu 
are modified. This menu has to be defined in the configuration file as well. A screenshot showing this menu is 
presented in Figure[6] 




Figure 6: Similar to Fig.[5]except that the <t> menu is opened. Both the event and geometry structures are visible. 
All the lines are green since all the objects are displayed. Hits position and charge are listed as well as the track 
properties. 

5.6 Mouse Interface 

In Frog, each object is clickable. When an object is clicked, some information about the objects are printed on 
the screen. As an example, when clicking on a track the momentum, the transverse momentum, the x 2 an d the 
number of hits are displayed. Object information to be printed are defined in the class of the selected object. But 
the selection routines is an important part of the core of Frog. (This is completely transparent for the Frog users, 
even for the users who want to add new objects). 

Thanks to the hierarchical structure of the objects it is possible to display the parent of a selected object when 
clicking on the key < 1 >, <2>, etc. For example if the selected object is a strip of a tracker module. Hitting < 1 > 
will display the module of the strip. Hitting <2> will display the grand-mother of the strip: the tracker. And so 
on, and so forth. The key <0> and <9> are special. The first just clean up the screen of the parent detectors that 
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have been displayed with <1> to <9>. While the <9> displays the full geometry of the detector. For complex 
detector this can dramatically slow down the rendering speed. 

5.7 Online Use 

Frog can be used online to have quickly clues on the quality of data taken by the experiment. This is transparent 
to the user, and usage of Frog online and offline only differs by the fact that in the online case, the Producer 
and the Displayer are used simultaneously. It is indeed possible to read the .vis file while the Producer is still 
pushing events into the same file. The temporary . vis file allows many users to look at the latest events without 
duplication of heavy and slow physics computation. 

It is possible to configure Frog in order to display always the latest event in the file, in order to see events as soon 
as they are written into the file. But even in that mode, the user can look at a particular event more deeply just by 
stopping the event changing (this is done with key <s>). 

5.8 Production of Pictures 

Frog can easily take screenshot of events and detector in order to produce publishable plots. There are two 
fundamental different ways to take screenshots. The first one, is just to copy all the pixels of the screen and encode 
them in a particular picture format (e.g. PNG). The second possibility is to store the information to build the 
picture. This is in general called a vectorial picture. Where objects are stored as a vector of primitives (lines, 
points, etc). Some well-known picture formats are using this technique (e.g. EPS, PS, PDF, etc.). 

In FROG, two picture libraries are used (so far) in order to work with the two pictures types. The Gl2ps library [ 8 ] 
is used for the vectorial format. It supports a lot of formats: PS, EPS, TEX, PDF, SVG and PGF. When a 
screenshot is taken (with the <ENTER> key) in that format (defined in the config file), only the active view is 
saved. Also, the output pictures are in general very heavy because of the high precision of that format. This is the 
ideal format to use to include Frog pictures in papers. 

For the pixelized picture, the PNGLIB [9] and ZLIB [7] libraries are used. This format should be used in all 
the other contexts because it allows to take screenshots faster and picture file size is lighter. It is also readable by 
almost every operating system without special softwares or add-ons. 

5.9 Styles 

Each Frog object contains a FROG_Style as data member, which contains all the style options. The styles can 
be changed directly in the configuration file. Styles of any group of objects can be changed just by using the group 
Eventld or Detld. Below is an example of the text block to setup styles of a RecoTrack Collection with and Eventld 
(23100001): 



Id_ 


.23100001. 


_Color = 


{ 1.0 


Id_ 


.23100001. 


_Thickness = 


3.0; 


Id_ 


.23100001. 


_Marker = 


0; 


Id- 


.23100001. 


_MarkerSize = 


5; 


Id. 


.23100001. 


_ShowDet 


false; 



The Color parameter is used to set up the default colour of the track Collection. The colour is defined as a vector 
of double contained between and 1. With the following syntax {Red, Green, Blue, Alpha}. The 
Thickness parameter defines the thickness of the line used to draw the track. Marker defines the type of the 
marker used to display the hits associated to the track. 

All the available markers can be found in FROG/ Re sources/ Marker/* .png. Anyone can add markers just 
by adding new . png picture with same width and height in this directory. MarkerSize is of course used to set 
up the size of the marker. Finally ShowDet defines if the detector module associated to the hits have to be drawn 
or not. In busy events it is recommended to put this parameter on false. 

If the style of an object is not defined, the style of his mother is used. If no parents have styles, unpredictable style 
is used. 
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6 Examples of Applications 

Frog is already used in different experiments and environments, some of them are shown in this section. The two 
examples described in this section show that FROG can be used in many different applications from the experiment 
to the simulation environement: GasTOF is a very small detector prototype iflOl . The second example, Delphes 
is not a detector but a framework for the fast simulation of the response of a generic detector in high energy 
physics ifTTI . 

6.1 GasTOF: The Ultra-Fast Gas Time-of-Flight Detector 

GasTOF [10] 02) detectors are Cherenkov gas detectors that will be located at 420 m from the CMS 0] and 
ATLAS flj] interaction point (IP), as part of the FP420 project [14) for the LHC Q5]. The aim of these detectors 
is to reduce backgrounds due to accidental coincidence of events detected in the central detectors and in the FP420 
detectors on each side of the IP. To achieve that, the event vertex z-coordinate measured by the central detectors is 
compared to the vertex reconstructed by measuring the time difference of forward proton arrivals to the GasTOF 
detectors on two sides of the given IP. It requires a very precise measurement of the proton time of flight (St ~ 10- 
20 ps). Cherenkov photons produced by high energy protons traversing gas medium are reflected by a mirror onto a 
very fast photomultiplier. In gases, thanks to small refractive index, these photons are emitted at very small angles. 

6.1.1 Display of the Geometry 

In the simulation, GasTOF is modelled as a finite cuboid volume filled with gas (C4-F10). Thanks to a toroid 
mirror placed inside the box, the Cherenkov photons are reflected and focused onto a small photocathode, leaving 
the box by a "window". All the elements are shown on Figure|7] for the 31 cm long GasTOF prototype used for 
the June 2008 test beam at CERN. 




Figure 7: A 3D View of the full GasTOF geometry (in wireframe). The gaseous Cherenkov detector is repre- 
sented by the green box. Inside the box, there is a toroid mirror (grey). A window (red) is present in the box 
to allow photons focused by the mirror to reach the GasTOF photomultiplier. The sensitive zone of the PMT 
photocathode is represented by the blue circle. Only the sensitive zone of the photomultiplier is drawn since the 
other parts do not affect the photon detection. 
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6.1.2 Display of the Events 

The figures below show the simulated GasTOF events comming from the ray-tracing done by the GasTOF 
simulator JT6). The Figure[8]shows 2D Y-Z projections of six different events while the Figure|9]shows a 3D view 
of an other event. In both cases, the Cherenkov photons paths (ray) are drawn in yellow. 




Figure 8: 2D views of six different GasTOF events: The proton trajectory (going from right to left in that 
view) is represented by the blue line. While photon trajectories (ray) are shown in yellow. The Cherenkov photon 
production is well visible along the proton path. The majority of produced photons are reflected by the curved 
mirror and focused on the photo-cathode. Note that some photons are not reflected on the mirror and than some 
others miss the PMT 




Figure 9: 3D view zoomed on the GasTOF mirror. Legend and colour codes have already been described in 
Figure [8] 



10 



6.2 Delphes: 

a Framework for the Fast Simulation of a General Purpose Collider Experiment 

Knowing whether theoretical predictions are visible and measurable in a high energy experiment is always delicate, 
due to the complexity of the related detectors, their data acquisition chain and their operating software. The 
DELPHES framework ifTTI has been introduced for the fast and realistic simulation of a general purpose experiment, 
like CMS or ATLAS at the LHC. The simulation includes the usual components of such detector as well as possible 
very forward detectors arranged along the beamline. 

The framework is interfaced to standard file formats (e.g. Les Houches Event File) and outputs observable analysis 
data objects, like missing transverse energy and collections of electrons or jets. The simulation of detector response 
takes into account the detector resolution, by smearing the kinematic properties of the particle. Usual reconstruc- 
tion algorithms are applied for complex objects, like the missing transverse energy or the jets originating from b 
quarks or r leptons. 

A simplified preselection can also be applied on processed data for trigger emulation. Detection of very forward 
scattered particles relies on the transport in beamlines. Finally, the visualisation of the collision final states is 
possible via a dedicated Producer interfacing Frog to DELPHES. 

A fast simulation can be used to obtain realistic observables and fast estimates of signal and background rates 
for specific channels. Starting from generator-level information, the package provides reconstructed jets, isolated 
leptons, photons, reconstructed charged tracks, calorimeter towers and the expected transverse missing energy. 

The overall layout of the general purpose detector simulated by DELPHES is shown in Fig.[lO]and[TT] A central 
tracking system surrounded by an electromagnetic and a hadron calorimeters. The muon system encloses the 
detector volume. A forward calorimeter ensure a larger geometric coverage for the measurement of the missing 
transverse energy. The fast simulation of the detector response takes into account geometrical acceptance of sub- 
detectors and their finite energy resolution. All detectors are assumed to be symmetric with respect to the beam 
axis. The configuration of the subsystems used in these examples is summarised in TableQ] 




Figure 10: Left: Layout of the generic detector geometry assumed in DELPHES. The innermost layer, close to the 
interaction point, is a central tracking system (pink). It is surrounded by a central calorimeter volume (green) with 
both electromagnetic and hadronic sections. The outer layer of the central system (red) consist of a muon system. 
In addition, two end-cap calorimeters (blue) extend the pseudorapidity coverage of the central detector. The actual 
detector granularity and extension is defined in the user-configuration card. The detector is assumed to be strictly 
symmetric around the beam axis (black line). Additional forward detectors are not depicted. Right: Profile of the 
layout assumed in DELPHES. The extension of the various subdetectors, as defined in Tab.Q] are clearly visible. 



System Extension in pseudorapidity 

Tracking < \r)\ < 2.5 

Calorimeters central < |?7| < 3.0 
forward 3.0 < \f]\ < 5.0 
Muon system < \rj\ < 2.4 

Table 1: Configuration of the subsystems used in the examples presented in Fig.[Toland[TT1 
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Figure 11: Layout of the generic detector geometry assumed in Delphes. Open 3D-view of the detector with 
solid volumes. Same colour codes as for Fig.[lO]are applied. Additional forward detectors are not depicted. 

As an illustration, an associated photoproduction of a W boson and a t quark is shown in Fig. [12] This corresponds 
to a pp — > Wt + p + X process, where the Wt couple is induced by an incoming photon emitted by one interacting 
proton. This leading proton survives from the photon emission and subsequently from the pp interaction, and is 
present in the final state. The experimental signature is a lack of hadronic activity in one forward hemisphere, 
where the surviving proton escapes. The t quark decays into a W and a b. Both W bosons decay into leptons 
(W — » [iv^ and W — ► tv t ). 




Figure 12: Example of pp(jp — > Wt)pY event. One W boson decays into a /i pair and the second one into 
a. t v T pair. The surviving proton leaves a forward hemisphere with no hadronic activity. The isolated muon is 
shown as the blue vector. The r-jet is the cone around the green vector, while the reconstructed missing energy is 
shown in gray. One jet is visible in one forward region, along the beamline axis, opposite to the direction of the 
escaping proton. 
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7 Future Developments 

Since Frog is a very flexible tool that can be considered more as a toolkit than as static software, many perspectives 
are possible for the evolution of the software. By design, Frog can grow very quickly because all the displayable 
objects are defined by their own C++ class inheriting from the same base class. Therefore, users can add new 
needed objects themselves in the software. Moreover, they can also add new types of view. 

All the basic tools are ready to be used in a larger scale. Some experiments already started to intensively use the 
software and numerous feedbacks from this large community of users helped to track bugs and improve the tool. 

The short term perspectives consist in the improvement of the tree menu in order to allow the user to change 
styles, colours, cuts, etc... directly from the menu. By this way, the users will not have to edit any more the Frog 
configuration file by themselves. 

An other improvement which will be implemented is the possibility to filter events contained in the .vis file 
directly from the Displayer in order to easilly find events satisfying simple criteria. 

On the long term perspectives, the possibility to turn Frog into a complete plug-in system will be investigated. If 
the code implementation is simplified for the user and performances are at least equal, the plugin system will be 
adopted. 

An other long term perspective is to improve the image quality of Frog by improving the 3D perspectives and 
effects. This can easily be done by adding lighting/shaddowing effects in the 3D scene. This makes in general the 
feeling of the perspective much better without adding too much complication in the code. This effect has also the 
advantage to be supported by any OpenGL VGA card. 

Of course, users' requests will also be included in the next releases. 

7.1 Frog Web Service 

In collaboration with the Caltech CMS group [ 18 ], a pilot project has been started. Its goal is to offer a Web service 
that allows users to easily produce the FROG visualisation files (.vis, . geom) from CMSSW [ 17 1 datasets. This 
service will offer to users, who do not necessarily have the full CMS software installed locally, a mean to remotely 
create and then download the Frog files. Since these .vis and . geom files are relatively small (^14Mb/200 
events) and the CMSSW processing time to create them is minimal, requests for Frog files from average sized 
datasets can be processed rapidly and downloaded quickly using standard broadband network connections. 

In the first phase of this project, the FROG Web Service will allow the selection of a CMSSW dataset (containing 
either simulated or real events) using an interface to DBS, a requested range of runs and/or event numbers, and a 
choice of which version of CMSSW is to be used to process the data into Frog files. In addition, a browsable and 
searchable set of previously created Frog files will be provided to the user. In a second phase, the Web Service 
would be enhanced to allow customized CMSSW configuration files to be uploaded to the server, and to allow the 
automatic creation of standard Frog projections/displays, which would be stored as graphics files on the server 
and made available for download via a photo gallery style interface. 
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8 Summary 



The goal of the Frog project was to create a new event display able to quickly display a significative fraction of 
the event data, in a high energy physics experiment. As a high rendering speed is desirable, the Frog software 
has been splitted into two parts: the Producer and the Displayer. In addition to the speed enhancement, this 
structure coupled with a "home-made" file format brings many interesting features for free, like the portability of 
the framework on several operating systems, the independence with respect to the experiment or environment, the 
possibility to share easily visualisation data, etc. Another important application of Frog is the online experiment 
data display, as the Producer and the Displayer can work simultaneously. 

In addition of the previous features, Frog is based on an object oriented design. Therefore, it can display almost 
any imaginable object without any sensitive lost of speed. It can work on almost any recent computer with one of 
the following Operating Systems: Linux, MacOs or Windows. The size of the full Frog package, including the 
source code, is less than 4 Mb. It is really suitable for outreach applications since it can be freely distributed and 
installed in only few clicks. Moreover, latest available data can be automatically downloaded from the internet by 
the Frog Displayer. One of the main goal of the Displayer was to allow a large number of users to visualise event 
data in quasi-real time. 

In conclusion, Frog can be used in many applications: it is highly tunable and allows a large number of users 
to visualise event data. The software is already used by several physicist communities for outreach and detector 
debugging. 
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9 Appendices 



Appendix A: Base Classes 

This appendix details some of the main classes used in Frog. The class diagram on Figure[T3]shows that all the dis- 
playable object classes inherit from FROG_Element_Base and/or FROG_Element_Base_With_Det Id. Clues 
on how these classes work are given for information, but users have not to modify any of the class described here, 
even if the user want to use the code for its experiment. The class FROG_Element_Primit ive.Line is used to 
give a short description of which methods a class associated to a displayable object has to contain. The hierarchy 
of the other Frog classes is shown in Figure [T4l 
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Figure 13: The Frog class hierarchy of the displayable objects. All the displayable object classes inherit from 
FROG_Element_Base. The three classes on the extreme left of this diagram are generally used as objects con- 
tainers (branch). 
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Figure 14: The FROG class hierarchy of the other objects like the different views. 
FROG_Element_Base 

All displayable Frog objects are represented by a class that inherit from FROG_Element_Base. This base 
class contains several methods used to read/write the data. These classes are used both by the Displayer and the 
Producer. 



Data Members 

unsigned short type_; 

unsigned int size_; 

unsigned char* data_; 
std::vector <FROG_Element_Base*> daughters_; 

FROG_Element_Base* mother_; 

unsigned char display_; 

unsigned int display_list_ 

FROG_Ob j ect s_Sty le * style_; 



The three first variables define the chunk: the Id, the size and the data, they are managed directly by the read ( ) 
and write () methods. The daughters, and mother, are necessary to navigate in the object's tree. The 
next variables are used to optimise the display. display_list_ stores a pointer to the object display list 1 19@ 
Finally, style_ contains the aesthetic properties of the object (e.g. colour, thickness, etc.) and the physical cuts 
(P™ n , E™ in , etc.) to be applied. 



Default Constructor 

The default constructor of FROG_Element_Base initialises the data to a null pointer, the type, and the 
size_. 



Writing method 

By design, the only data contained in FROG_Element_Base object are sub-chunks, it is a brancfFl So, the 
write method of this class has only to store the objects contained in the daughters, variable into the data_ 
data member. 

2 ' A display list is a compiled version of the display code stored in the graphic card memory. It is used to improve the rendering 
speed. 

^ if the chunk Id is equal to C .PRIMARY the branch is actually the root. 
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// Fill data_ and size_ with data 
virtual void write () { 

std::vector< std: :pair<unsigned int, unsigned int > >* blockOf Daughters ; 

blockOf Daughters = write_init ( ) ; 
if (blockOf Daughters==NULL) return; 
write_daughters (blockOf Daughter s ) ; 



The write_init ( ) method set up the object and its daughters for storing: it allocates memory, it looks for the 
optimal storing strategy, etc. The outputs of this function are groups of objects that have to be stored in a same 
chunk. This output is used by write.daughters ( ) which fill the variable data, that will be used later to 
produce the .visor . geomfile. 

Reading method 

The read ( ) is not really implemented in this class. 
Initialisation method 

FROG.Objects is a global structure containing useful variables like the events collection, the geometry, the 
parameters read from the configuration files, etc. The init (...) method is used to share this pointer to the 
entire tree and to reset the object styles and cuts to its initial state using configuration parameters. 

Display 

The display is done by virtual void display (bool UseDisplayList=true, float* color=NULL). 
The display lists [ 19 1 improve rendering performances, but in some particular cases, they can not be used, this is 
the reason of the first argument of display. The second argument is a pointer on a float [4] that contains the 
four components of the colour to use for the object to be drawn. When this argument is NULL, the colour used is 
taken from the style- variable. 

In the case of a FROG_Element_Base the display function just call iteratively the display of its daughters and 
put the result in a display list. 

FROG_Element_Base_With_DetId 

In large physics experiment, it is convenient to identify each subset of detectors/data; this Id is generally simply an 

integer. For this reason, the FROG_Element_Base class has been extended to a class called FROG_Element_Base_With_Det I 

It is a perfect clone of the base class, except that it contains an extra variable det Id_ of type uns igned int. 

Writing method 

This new data members is saved by the write ( ) method of the extended class. 

// Fill data_ and size_ with data 
virtual void write (){ 

std::vector< std : : pair<unsigned int, unsigned int > >* blockOf Daughters ; 

blockOf Daughters = write_init ( ) ; 
if (blockOf Daughters==NULL) return; 

data_ = FillBuf fer (data_, &detld_, sizeof (int) ) ; // write the detld_ 
write_daughters (blockOf Daughter s ) ; 



This class has itself been extended to a FROG_Element_Base_With_DetId_And_Name which contains a string in addi- 
tion of the integer. 
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This extended write ( ) method is completely identical to the write ( ) of the base class except that it contains 
an extra line that copy the value of detlcL in data_. Similarly, the FROG_Element_Base_With_DetId 
constructor has to be modified to properly initialise the det Id_, when reading from a file ( . geom or .vis). 

Reading method 

FROG_Element_Base_With_DetId (unsigned short type, FILE* pFile) : 
FROG_Element_Base (type) { 
size_ = sizeOf (); 

f read (&detld_ , sizeof (detld_) , 1, pFile) ; 

} 



sizeOf () method 

The size of the chunk has changed, so the s i z e f ( ) method has to be updated: 

static unsigned int sizeOf () { 

return 6 + sizeof (unsigned int); 

} 

The sizeOf method always returns the number of bytes needed to store an object of this class, it is always 6 plus 
the sum of the sizeof ( ) of all variables stored by this object. This exetend class contains new functions related 
to det Id_: a method to get the det Id, a method to look for an object with a given det Id, etc. 

The Reading Procedure 

The reading procedure is handled by a global Read method, which scans iteratively all the chunks contained in 
a file until the number of bytes read exceed the expected number of bytes to read. A pointer to the mother object 
is given as an argument of this function, this allows to attach objects created from sub-chunks as daughters of a 
mother. When a chunk with a known chunk Id is found, a new object of the proper type is created as a daughter 
of the mother chunk. If this chunk type can contain sub-chunks, the Read method is called recursively using the 
new object as the mother. The number of bytes to read is computed from the chunk size and from the number 
of byte already read. The example below shows what is done when a chunk of Id C_FEL^ is found in the file: 

case C_FEB: 

TemporyEleraent = new FROG_Element_Base (chunk_type) ; 
mother->addDaughter (TemporyEleraent ) ; 

chunk_read += Read (pFile, TemporyElement , chunk_size-chunk_read) ; 
break; 

} 

When the chunks contains data in addition of sub-chunks, the data are read using the object constructor 
with the file pointer in argument, the number of bytes read by the constructor has to be counted as well. The 
FROG_Element_Base_With_DetId is a perfect example of such an object, the code below describes what is 
done when a chunk Id of that type is found : 

case C_FEB_DETID: 

TemporyElement = new FROG_Element_Base_With_DetId (chunk_type, pFile) ; 
mother->addDaughter (TemporyElement) ; 

chunk_read += FROG_Element_Base_With_Det Id : : sizeOf ( ) -6 ; 
chunk_read += Read (pFile, TemporyElement, chunk_size-chunk_read) ; 
break; 

The code below is used when an unknown chunk Id is found, which generally indicates a file corruption or in- 
compatibilities. The unknown chunk is simply skipped and a warning message is printed out. The program will 
anyway display the other objects. 

5) C.FEB is the Id associated to the FROG_Element_Base. 
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default : 

printf ( "Unknown ChunkID ( %i ) \n" , chunk_type ) ; 
printf ( "Chunk will be skipped\n" ) ; 

printf ("The program may be not running properly\n" ) ; 
f seek (pFile, chunk_size-chunk_read, SEEK_CUR) ; 
chunk_read += chunk_size-chunk_read; 
break; 

FROG_Element_PrimitiveXine 

This section details as an example the implementation of a leaf: FROG_Element_Primitive_Line object that 
is used to draw a line segment in a 3D space. This object is a leaf since it contains data but no sub-chunks. It can 
be used for the detector geometry design but also for the events representation, for example, a track in a detector 
without magnetic field is generally displayed as a straight line. The class and variables declaration are done with 
this code: 

#include "FROG_Element_Base_With_Det Id . h" 

class FROG_Element_Primitive_Line : 
public FROG_Element_Base_With_DetId { 
public : 

float P1X; float P1Y; float P1Z; 

float P2X; float P2Y; float P2Z; 

FROG_Ob jects* f rogOb jects_; 

float variables are the positions of the two points of the line in cartesian XYZ coordinates. The FROG_Ob jects* 
variable is a container for few global parameters. Since FROG_Element_Primitive_Line inherits from 
FROG_Element_Base_With_DetId, the line object has also a detld that can be used to access the object 
to define its style for instance. The method isCompactible returns true if the object has a fixed size and the 
method sizeOf returns the size of an unique chunk. This object has a fixed size of 34 ByteJ^l 

virtual bool isCompactible () { 
return true; 

} 

static unsigned int sizeOf(){ 

return FROG_Element_Base_With_DetId: : sizeOf ( ) + 6*sizeof (float) ; 

} 

The class constructor is defined below: 

FROG_Element_Primitive_Line ( 
unsigned int detld, 

float plX, float plY, float plz, 
float p2X, float p2Y, float p2Z) : 

FROG_Element_Base_With_DetId (C_PRIMITIVE_LINE, detld) , 
PlX(plX), PlY(plY), PlZ(plZ), 

P2X(p2X), P2Y(p2Y), P2Z(p2Z) 

{ 

size_ = sizeOf ( ) ; 

} 

The arguments of the FROG_Element_Base_With_Det Id constructor are the chunk type (C_PRIMITIVE_LINE) 
and the detld. The class needs a second constructor that build the object from the input file. 



6) SizeOf(EmptyChunk) + 6*SizeOf(float) + SizeOf(DetId) = 6 
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FROG_Element_Primitive_Line (FILE* pFile) : 
FROG_Element_Base_With_DetId (C_PRIMITIVE_LINE) 
{ 

size_ = sizeOfO; 

f read (&detld_ , sizeof (detld_) ,l,pFile) 

fread(&PlX ,sizeof(PlX) ,l,pFile) 

fread(&PlY ,sizeof(PlY) ,l,pFile) 

fread(&PlZ ,sizeof(PlZ) ,l,pFile) 

fread(&P2X ,sizeof(P2X) ,l,pFile) 

fread(&P2Y ,sizeof(P2Y) ,l,pFile) 

fread(&P2Z ,sizeof(P2Z) ,l,pFile) 



Data have to be read/written in the same order. Since the object do not contain daughters, the write ( ) is easyer 
than FROG_Element_Base_With_DetId: : write () . 



virtual void write () { 



size_ 


= sizeOf ( ) ; 






data_ 


= new unsigned char [ size_-6 ] ; 




data_ 


= FillBuffer( 


data_, &detld_, 


sizeof (detld_) ) ; 


data_ 


= FillBuffer( 


data_, &P1X, 


sizeof (FIX) ) ; 


data_ 


= FillBuffer( 


data_, &P1Y, 


sizeof (P1Y) ) ; 


data_ 


= FillBuffer( 


data_, &P1Z, 


sizeof (P1Z) ) ; 


data_ 


= FillBuffer( 


data_, SP2X, 


sizeof (P2X) ) ; 


data_ 


= FillBuffer( 


data_, &P2Y, 


sizeof (P2Y) ) ; 


data_ 


= FillBuffer( 


data_, &P2Z, 


sizeof (P2Z) ) ; 


data_ 


= (unsigned char*) ((unsigned 


long) data_ - (size_-6) ) ; 



The data_ array is directly initialised by the write function. The object data are iteratively copied in the data_ 
variable with the FillBuf f er function. The buffer cursor is moved back to the beginning of the buffer. 

The init is generally called two times. At the first time, the argument of the function will points to a FROG_Ob ject s *, 
while at the second call the pointer is NULL. 



virtual void init (void* f rogOb jects ) { 
if (frogObjects !=NULL) { 

frogObjects_ = (FROG_Ob jects* ) frogObjects; 
}else if (f rogOb jects==NULL && frogObjects_ != NULL) { 
if (mother_! =NULL& &mother_->style_ !=NULL) { 

style_ = new FROG_Ob jects_Style (mother_->style_) ; 
} else { 

style_ = new FROG_Ob jects_Style ( ) ; 

} 



frogOb ject s_->frogCard_->Get Color ( 

style_->color_ , " Id_%i_Color " ,detld_); 

f rogOb ject s_->f rogCar d_->Get Float ( 

&style_->thickness_ , " Id_%i_Thickness " ,detld_ 



If the method's argument is NULL, the init reads the colour and thickness parameters from the configuration 
file, using f rogOb jects_->f rogCard_->Get . . . and store them into the style_. If no parameters are 
given, the default colour and thickness value of the mother is used. Finally the display method is almost only 
OpenGL code: 
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#ifdef FROG_OPENGL 

virtual void display (bool UseDisplayList=true, float* color=NULL) { 
// first Init Colors & Style! 
init (NULL) ; 

glLineWidth (style_->thickness_) ; 

if (color) {glColor4fv (color) ; }else{glColor4fv( style_->color_) ; } 
glLoadName ( detld_ ); 

glBegin (GL_LINES); 

glVertex3d (P1X, P1Y, P1Z); 

glVertex3d (P2X, P2Y, P2Z); 
glEndO ; 

} 

#endif 

First, the style is set by init (NULL) . The right colour and thickness to used are transmitted to OpenGL for the 
line drawing, glLoadName is used to give an OpenGL name to the displayed line, this is need to allow mouse 
selection of the object (see sec. 15. 6t . Finally, the line is drawn by giving the two vertex positions between the 
markup glBegin (GL_LINES) and glEnd ( ) . 

An extra method can be added to display some text when the object is mouse selected. 

virtual void printlnf os (char* buffer) { 

sprintf (buff er, "LINE : Hitl : x=%f y=%f z=%f " , P1X, P1Y, PIZ ) ; 
sprintf (buff er, "LINE : Hit2 : x=%f y=%f z=%f " , P2X, P2 Y, P2 Z ) ; 

} 

The function just fill a text buffer with the text to print on screen when the object is selected. 

These are all the functions an advanced user needs to implement in order to add its own objects toolkit. More than 
25 object classes can be found in FROG/FROG_Element_* . h that can be used as object class examples. 

Geometry and Events Classes 

These two classes handle the Frog Elements tree, which is one of the private data members. The classes also 
contains specific functions useful to display only few parts of the geometry and/or the events. In order to keep the 
random-access memory used by the Displayer reduced, the event class loads the events one by one. When the next 
event has to be drawn, the current event is firstly unloaded and only then, the next one is loaded. This technique 
is not applicable for the geometry data because the event processing can request for a detector part information at 
any time. So it is more efficient to load the entire detector geometry at the beginning and to keep it in memory up 
to the end. 

These two classes will also take the Frog element tree writing in charge. The basic Frog user is not supposed to 
deal with the FROG_Element_Base. Those are just internal format used by the Geometry and Events classes to 
read, write and display objects. This fact will be shown in the next section. 
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Appendix B: Complete Example 



This section shows an example of code used for a fictitious tracking experiment composed of a particle source 
beam, eleven tracking layers and a block to stop the beam. Others examples/tutorials are also available online as a 
tutorial [ 5 1 . 

Producer Code 

The Producer code is divided into four different methods: main, Build_Geometry creates and stores the ge- 
ometry of the detector, BuilcLEvents and BuilcLlEvent simulate and store the events. The code includes 
the needed Frog classes, and defines the functions implemented in the file. Eventually, the main is implemented. 

#include <stdio.h> 
#include <iostream> 
#include <math.h> 

#include "FROG/FROG_DetId . h" 
#include "FROG/FROG_Geometry . h" 
♦include "FROG/FROG_Events . h" 
♦include "FROG/FROG_Element_Tools . h" 

void Build_Geometry ( ) ; 
void Build_Events () ; 

void Build_lEvent (FROG_Element_Event* event); 

int main ( ) 

{ 

Build_Geometry ( ) ; 
Build_Events ( ) ; 

} 

The Build_Geometry function creates the tree structure that is stored in the file. The root of the tree 
is necessary a FROG_Element_Base with a C -PRIMARY chunk Id. The geometry branch is created and at- 
tached to this primary object. Other branches are created to reflect the detector structure, since they are of type 
FROG_Element_Base_Width_Det Id_And_Name, those branches contain a unique detld that will be used to 
access the branch, and a string that give a name to the branch (e.g., "TRACKER" or "OTHER"). The eleven 
tracking layers are created in a loop and are represented by a rectangle attached to the "TRACKER" branch. 

void Build_Geometry ( ) 

{ 

FROG_Element_Base* prim = new FROG_Element_Base (C_PRIMARY) ; 
FROG_Element_Base* mygeom = new FROG_Element_Base (C_GEOMETRY) ; 
prim->addDaughter (mygeom) ; 

FROG_Element_Base_With_DetId_And_Name* tracker; 

tracker = new FROG_Element_Base_With_Det Id_And_Name ( 900 00 00 , "TRACKER" ) ; 
mygeom->addDaughter (tracker) ; 

unsigned int DetldCount = 1; 

// TRACKING LAYERS 
for (int i = 0; i<=10; i + + ) 
{ 

FROG_Element_Primitive_Rect angle* layer; 
layer = new FROG_Element_Primitive_Rectangle ( 

400000000+DetIdCount, // Detld 

, , 50*i, // Position 

50,0,0 , // Width 

,50,0 ) ; // Length 
tracker->addDaughter (layer) ; 
DetIdCount++; 

} 
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The ending block that stops the particles and the particle source are attached to the "OTHER" branch. They are both 
represented by a cuboid volume. Finally, a Frog_Geometry object is created from the root of the data structure. 
The Frog_Geometry::SAVE() creates and fill the ouput file of name "MyCustomTracker . geora". 

FROG_Element_Base_With_DetId_And_Name* others; 

others = new FROG_Element_Base_With_Det Id_And_Name ( 8 000 , "OTHER") ; 
mygeom->addDaughter (others) ; 

// END BLOCK 

FROG_Element_Primitive_Cube* End = new FROG_Element_Primitive_Cube ( 



4 00 00 00 00+DetIdCount, 


// 


Detld 


,0 , 600 , 


// 


Position 


50,0 ,0 


// 


Width 


,50,0 


// 


Length 


,0 ,50 ) ; 


// 


Thickness 



others->addDaughter (End) ; DetIdCount++; 



// PARTICLE GUN 

FROG_Element_Primitive_Cube* PG = new FROG_Element_Primitive_Cube ( 

400000000+DetIdCount, // Detld 

,0 ,-300, // Position 

5,0,0 , // Width 

0,5,0 , // Length 

0,0,50); // Thickness 

others->addDaughter (PG) ; DetIdCount++; 

FROG_Geometry* CustomGeom = new FROG_Geometry (prim) ; 
CustomGeom->Save ( "MyCustomTracker . geom" ) ; 
delete CustomGeom; 



return; 



} 



The Build_Events method creates the data tree that will contain all the new events. Hundred events are created 
and push in this tree. The events are of type FROG_Element_Event, the run and event numbers are given as an 
argument of the constructor. Once the new event has been filled by BuilcLlEvent, and pushed in the data tree, 
they are stored on disk (one by one) by FROG.Events : : SavelnLive. The arguments of the function are used 
to set : the output file name, if the file has to be gzipped, if it has to be closed, and the maximum file size in bytes. 
The return value is FALSE when the new event will make the file size exceeding the maximum allowed file size 
(2 MB in this case). At the end, SavelnLive is call a last time to force the closing of the file. 

void Build_Events ( ) 

< 

FROG_Event s * events = new FROG_Events ( ) ; 
for (unsigned int i=0 ; i<10 ; i++ ) { 

FROG_Element_Event* event = new FROG_Element_Event ( 1 , i ) ; 

Build_lEvent (event) ; 

events->AddEvent (event) ; 

if ( ! event s->SaveInLive ( " SimulatedEvents . vis " , false, false, 2000000)) 
{ 

printf("File Size Exeeded 2.000.000 bytes\n"); 
printf("Stop here\n"); 
exit (0) ; 

} 

} 

event s->SaveInLive ( "SimulatedEvents .vis", true, false, 2000000) ; 
delete events; 

} 
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The method BuilcLlEvent simulates and stores one event. The simulation consists a straight line propagation 
of the particle using a random emission angle from the particle source. During the propagation, a new hit is created 
and attached to the data tree, each time the particle is crossing a tracking layer. The data structure is such that the 
hits are contained in a track itself contained in a track collection. 



void Build_lEvent (FROG_Element_Event* event) 

{ 

// Particle Gun direction and strength 
double phi = ( rand ( ) %3 60 ) *0 . 1 74 5 ; 
double theta = (rand()%8) *0. 01745; 
double P = 10; 



/ / Particle Gun position 
double pos_x = 0; 
double pos_y = 0; 
double pos_z = -300; 



// Particles direction (cartesian coord) 
double dir_x = P*cos (phi ) *sin (theta) ; 
double dir_y = P*sin (phi ) *sin (theta) ; 
double dir_z = P*cos (theta) ; 

double Pt = sqrt (dir_x*dir_x + dir_y*dir_y) ; 



FROG_Element_Base_With_DetId_And_Name* Tracks ; 

Tracks = new FROG_Element_Base_With_Det Id_And_Name (EVTID_TRK, "Track Collection"); 
FROG_Element_Event_Track* track= new FROG_Element_Event_Track ( , P , Pt , ) ; 



/ / Propagation loop 
double dt = 0.1; 

for (unsigned int i=0 ; i<l 00 00 ; i++) 
{ 

pos_x += dir_x * dt; 
pos_y += dir_y * dt; 
pos_z += dir_z * dt; 

if (pos_z<0 | I pos_z>=600) continue; 



// Is the particle crossing a tracking layer — > if yes, creates a hit 

if ( ( (int) pos_z) %50==0 && fabs (pos_x) <=50 && f abs (pos_y ) <=50 ) 

{ 

FROG_Element_Event_Hit* hit = new FROG_Element_Event_Hit ( 

400000001 + ( (int) pos_z) /50, // Detld 
pos_x, pos_y, pos_z, // position 

-1) ; // dEdx 

track->addDaughter (hit) ; 

} 

} 



Tracks->addDaughter (track) ; 
event->addDaughter (Tracks) ; 



return; 

} 



This simple example shows how a user can display his experimental setup using Frog in only few lines of code. 
The standard Frog package contains already more than 25 objects that can be used to render the detector geometry 
and events. Those classes have been shown in the Figure [T3] In addition of those several available classes, the 
users can also create new classes to display particular objects that fit his needs, a tutorial is available online Q. 
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Configuration Code 

The ASCII code below is the configuration file used to run FROG on the fictitious tracking experiment. 



InputVisFile 
InputGeom 



{ SimulatedEvents . vis } ; 
{MyCustomTracker . geom} ; 



/ / Input event file 
// input geometry file 



GeomToDi splay 
Event ToDi splay 



{9000000 , 8000000] 
{23100000 } ; 



// Tracks 



Event_Number = ; 

Event_Time = 30; 

Geometry_WireFrame = true; 

Screenshot_Format = png; 



// first event number 
// event will change every 30 Sec 
// Geometry is draw as wireframe 

/ / Screenshot format 



BackGround_Color 
Txt_ Color 
ZAxis _Color 
ZAxis Thickness 



{1.0 
{0.0 
{1.0 
0.0; 



1.0 , 1.0 }; 

0.0 , 0.0 , 1.0}; 

0.5 , 1.0 , 0.3}; 



// White 
// Black 
// Red+Blue 



Id_23100000_Color = { 1.0 , 0.0 

Id_23100000_Thickness = 4.0; 
Id_23100000_Marker = 100; 
Id_23100000_MarkerSize= 5; 
Id_9000000_Color = { 0.4 , 0.4 

Id_8000000_Color = { 0.4 , 0.4 



. 



1 . 
. 4 



1.0 }; // Tracks 

// Tracks 

// Tracks 

// Tracks 

0.5 }; // Tracking Layers 

1.0 } ; // End Block 



ActiveViews 



{View3D, View2DZ, View2DR, ViewMenu}; 



View3D_Type 




3D; 




View3D_Viewport_X 




. 




View3D_Viewport_Y 




. 3 




View3D_Viewport_W 




1.0 




View3D_Viewport_H 




. 8 




View3D_Cam_Pos_Theta 




0.3 




View3D_Cam_Pos_Phi 




0; 




View3D_Cam_Pos_R 




500 




View2DZ_Type 




2D; 




View2DZ_Viewport_X 




0.4 




View2DZ_Viewport_Y 




. 




View2DZ_Viewport_W 




. 6 




View2DZ_Viewport_H 




0.2 




View2DZ_Cam_Pos_Phi 




0.01; 


View2DZ_Cam_Pos_R 




600; 


View2DZ_Slice_Depth 




800 




View2DR_Type 




2D; 




View2DR_Viewport_X 




. 1 




View2DR_Viewport_Y 




. 




View2DR_Viewport_W 




0.2 




View2DR_Viewport_H 




0.2 




View2DR_Cam_Pos_Phi 




1.57; 


View2DR_Cam_Pos_R 




100 




View2DR_Slice_Depth 




1000; 


ViewMenu_Type 




Menu; 


ViewMenu_Viewport_X 




0.15; 


ViewMenu_Viewport_Y 




0.05; 


ViewMenu_Viewport_W 




. 7 




ViewMenu_Viewport_H 




. 9 




ViewMenu_Alpha 




. 8 
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